-
Notifications
You must be signed in to change notification settings - Fork 112
Conversation
This can become a hot-spot.
3cbe74d
to
a19b05e
Compare
// called frequently. | ||
|
||
// Add each regular want-have / want-block to the message. | ||
if msgSize+(len(peerEntries)*bsmsg.MaxEntrySize) > mq.maxMessageSize { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're now eagerly sorting which could affect performance. However, I believe the real perf issue was that we were repeatedly sorting the same broadcast list over-and-over, which we're now doing at most once per change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but I would love to see a test to make sure the cache-busting and sorting works as expected.
Also I assume there was a performance bottleneck observed in production that motivated this change. I suggest we observe performance in the same situation before merging to make sure this solves the problem.
This test explicitly calls entries to make sure the cache is materialized.
Sorting test is go-bitswap/wantlist/wantlist_test.go Line 206 in a19b05e
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
feat: cache the materialized wantlist This commit was moved from ipfs/go-bitswap@d48cbc1
This can become a hot-spot.